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OverviewData_tTransferwith the Windews 95 Shelt 


The OLE 2 Specification defines the mechanisms for doing data transfer between 
applications. This includes Drag & Drop and the Clipboard (cut copy paste). This 
document is an amendment to that information, describing the details necessary to 
do data transfer with the Windows 95 shell and serves as a guide for application 
writers, suggesting the features they should implement and the issues they will 
need to address. This document will focus mostly on the drag drop case, as it is 
more complicated than the clipboard based transfers. But the peculiarities of the 
clipboard will be covered as well. 


The Basics 


Readers of this document should be familiar with these basic OLE concepts; 
embeddings, links, containers, servers, data objects, CLSID, GUID, drag and drop, 
and the clipboard. Here is a quick (hopefully) summary of the important ideas: 


Clipboard Format - A clipboard format is a definition of a standard data type that 
is transferred through the clipboard or through a drag drop operation. Common 
clipboard formats include CF TEXT (plain text), “Rich Text Format” (formatted 
text), CF BITMAP (a raster bitmap image), CF METAFILEPICT (a windows metafile, 
which is an object based graphic), “embedded source”GF-EMBEDSOURCE and 
“embedded object” OLE embedded-ebject. Applications can define their own private 
formats for internal use, as well as public formats that other applications may wish 
to support. This document will describe how these formats are used for transfer 
with the shell, as well as document the new formats the shell uses for new types of 
transfers. Clipboard formats are usually referred to as CF <type> or by the string 
representation (“Rich Text Format”) which is used for registered clipboard formats 
(formats beyond the standard ones defined by windows). 


Storage Medium (STGMEDIUM)- This is an OLE idea that represents a method of 
storage for some data, often used with clipboard formats. The storage types of 
interest for this discussion are HGLOBAL (a block of memory), [Storage (and OLE 
structured storage or docfile), [Stream (an OLE stream of data). There are other 
formats, see the OLE documentation for further details. Storage mediums are used 
to transfer potentially large objects without having to have them exist entirely in 
memory, as well as providing the data in the structured storage format that objects 
are typically persisted in. 


Data Object - A Data Object, often referred to as an [DataObject, is an OLE concept 
that is an encapsulation of some data. A data object can contain multiple clipboard 
formats and that data can be offered on any of the standard storage mediums. The 
simplest case is CF_TEXT on TYMED HGLOBAL, which is a chunk of text ina 
memory block. But typically a data object contains a list of formats that represent 
the data at different levels of fidelity. For example a word processor typically offers 
a selection of text as CF TEXT as well as “Rich Text Format”. Simple apps will take 
CF TEXT, but more sophisticated apps will take rich text. The data object is the 
basis of data transfer, either through the clipboard or through drag and drop. So all 
things that are to be transferred need to be described in a data object, and 
ultimately that is a collection of clipboard formats. 


Drop Effect or DROPEFFECT values. These are the standard transfer types, move, 
copy or link. All transfer operations are describes as one of these. If the intersection 
of the effects offered by the source, and accepted by the target is empty no transfer 
can occur (i.e. a source can allow things to be copied, and if the target will only 
accept moves no action will take place). In cases where more than one effect is 
allowed keyboard modifiers or the selection from a menu (in the case of a right 
mouse drag) are used to determine which transfer operation to perform. 


Drop Source - or [DropSource. This is an interface that is used to control the 
operation of the drag and drop from the source of that drag. This code decides what 
actions terminates the drag drop, usually the mouse button going up. The source of 
a drag can only control what happens at the target by putting the appropriate 
formats in the data object and passing the allowed drop effects, it is up to the target 
to implement the data transfer on the drop, this is a common point of confusion. 


Drop Target - or IDropTarget. Targets of drag drop transfers implement this 
interface. This code takes the data object, the state of the keyboard, and the mouse 
buttons, and performs the transfer when the drop occurs. This code also decides if a 
drop is allowed this usually means the contents of the data object are examined as 
well as the allowed drop effects. If the data object contains formats that the target 
recognizes it sets the cursor appropriately and does any target highlighting as 
necessary. 


DoDragDropO - This is the OLE API that applications call to being a drag drop. 
The input to this is the data object that represents the thing being dragged, as well 
as the allowed drop effects. The return from this function indicates if a move 
happened, signaling the source to delete it’s data. Typically the caller of this API 
does not know on what the drop occurs, although I will discuss a convention for 
communicating this information below. 


RegisterDropTargetQ - this is the OLE API that targets use to register a window 
as a drop target. All targets must be registered with OLE to participate in the drag 
drop party. 


Brief history of drag and drop 


Windows 3.1 defined a way for applications to accept files being dragged from the 
File Manager. This involved responding to the WM DROPFILES message and was 
independent of the OLE drag and drop protocol. Applications that wanted to accept 
files as well as data through OLE had to implement both methods. Under Windows 
95 the clipboard format CF HDROP is used to allow this same functionality, and for 
applications that accepted WM DROPFILES the OLE drag loop will simulate the File 
Manager functionality if the source data object contains CF HDROP. This lets 
applications be drop sources for files, and allows files to be dropped on applications 
that were not written with OLE drag and drop in mind. This magic is implemented 
inside the OLE drag loop. There is some potential confusion if an app is a 

WM DROPFILES and an OLE target. The OLE drag loop will indicate that a drop 
can occur, and send a WM _DROPFILES message if the source data object contains 
CF HDROP and the target is a WM DROPFILES capable, this is independent from 
the response to the IDropTarget’s responses. 


In summary, Windows 95 drop targets can remove all of the WM DROPFILES code, 
and just be an OLE target that accepts CF HDROP. For sources, they can add 

CF _HDROP to their data object if appropriate, and have drag and drop work to 
WM_DROPFILES apps, as well as new CF_HDROP apps. 


New clipboard formats 


To participate with the Windows 95 shell using drag and drop and the clipboard you 
need to understand the clipboard formats that are used to represent the objects 
being transferred. The most common object is a file, but there are formats that 
describe folders, printers, network objects and more. 


See the definition of these formats in shlobj.h. For each format a CFSTR_ has been 
defined, use that to register these format with RegisterClipboardFormat(). 

Also see the Win32 SDK, Guides, Programmers’ Guide to Windows 95 for more 
details on these topics. 


CF HDROP - This is a list of fully qualified path files and folders path names. This 
format is important for applications that want to accept files being dragged, and is 
the most commonly used format. When this format is present in the data object the 
OLE drag loop will simulate the WM DROPFILES functionality to non OLE drop 
targets. This is important if you want to be the source of a drag drop operation on 
files and have Win 3.1 WM DROPFILES targets accept those files. Note that this 
format is appropriate to transfer locations of existing files and folders. If a new file 


should be created as the result of the transfer operations, 
FILECONTENTS/GROUPFILEDESCRIPTOR (described below) is muchmere- 


appropriate. This format has an ANSI and UNICODE representation. So be careful 
constructing this, interoperability with Win95 and NT requires using the using ANSI 
on Win95 platforms. 


FILECONTENTS, FILEGROUPDESCRIPTOR (FILEDESCRIPTOR). These clipboard 
formats identify data that is appropriate to be saved as a file. That is the format of 
the data is the same as a standard file format. These also allow for the creation of 
file system folders (by setting the dwAttributes in the FILEDESCRIPTOR) and 
groups of files in sub folders. Setting FD _LINKUI in the 
FILEGROUPDESCRIPTOR.fdg[0].dwFlags lets you force the system to present 
“Create Shortcut” UI (the shortcut arrow on the drag image and “Create shortcut in 
the non default drag case). This is appropriate if the data you are offering is a 


shortcut file type (.URL, .SHB, .LNK, etc.). For IE4 (and subsequent UI releases) 
FD_LINKUI is replaced with “Prefered DropEffect” (see below), but both are 
supported for compatibility. 


Note: FILEGROUPDESCRIPTOR has an ANSI and Unicode definition (A/W). Win95 
does not support the Unicode version. 


NETRESOURCE. This clipboard format identifies_a network resource object, such as 


a domain or a server. When the user drags such an object from the shell, its 
IDataObject contains this format of data. The drop target can pass this data to any 


WNet API (such as WNetAddConnection) to perform network operations on those 
objects. 


OFFSETS. Used to position items after the transfer has occurred. This is an array of 
POINTs that needs to be coincident with the other data formats (CF_HDROP, 
FILECONTENTS) in the data object. 


PRINTER 


“Shell IDList Array” CF _HIDA. This clipboard formats indicates the absolute 
(relative from the Desktop) location of the transferring objects in the shell’s name 


space. Every object the user can browse from the explorer has an IDList which 
uniquely identifies it in the name space. Application programs don’t need to deal 


with this format of data unless they need to handle heterogeneous objects (like 
printers, control panels, etc.). 


“FileName” - this is partially supported (for compatibility only). CF HDROP is the 
same thing, while supporting a list of file names instead of just a single file. This 
format is offered by the shell solely to support existing Windows 3.1 application 
programs which expect to see this format of data in the clipboard. All new Windows 
95 application programs should use CF HDROP instead. 


“Uniform Resource Locator”. 
This is plain text (Same as CF_TEXT), but this text is known to be a URL. This is 
useful for internet related cases. 


New For lE4 


“Preferred DropEffect” - This is an HGLOBAL that contains a DWORD that is one of 
the DROPEFFECT_ values. In the cut/copy/paste case this lets “delete on paste” (see 
below) sources communicate to the target so the “optimized move” (see below) can 
be implemented. This format communicates whether cut (DROPEFFECT MOVE) or 
copy (DROPEFFECT COPY) was chosen at the source. For drag and drop this lets 
the source communicate a preferred default type of transfer (i.e. move and copy can 
both be supported but a drag source might provide a preferred effect as a hint that 
one might be more appropriate for the given DataObject). 

There are also cases where the existence of “Preferred DropEffect” is used for 
performance or functionality enhancements. For example, if a DataObject with the 
FILECONTENTS and GROUPFILEDESCRIPTOR formats also has “Preferred 
DropEffect”, containers may use this information instead of checking for the 
FD_LINKUI bit. This is a performance win for sources when the 
IDataObject::GetData on a GROUPFILEDESCRIPTOR is expensive. (Sources should 
still set the FD LINKUI bit for compatibility with old targets that do not understand 
“Preferred DropEffect”) 


“Performed Effect” - This is an HGLOBAL that contains a DWORD that is one if the 
DROPEFFECT_ values. Unlike most clipboard formats, this format is not provided by 
the source, instead the target calls IDataObject::SetData to communicate back to 
the source. In the drag-drop scenario this lets the drop target notify the source what 
the final effect was and whether it was an optimised drop. For Example OLE 
specifies that for an optimised move (a move occurred and the source has no 
cleanup to do), the dwEffect returned from IDropTarget::Drop is 0. However 
because of backwards compatibility with Win95, the dwEffect returned from 
IDropTarget::Drop is DROPEFFECT MOVE. Instead, the “Performed Effect” 
clipboard format will reflect the dwEffect that should have been returned from 
IDropTarget::Drop, so it will contain 0 if an optimised move took place. 


“Paste Succeeded” - This is an HGLOBAL that contains a DWORD that is one of the 
DROPEFFECT_ values. This format is intended for “delete on paste” sources to be 
able to interoperate with arbitrary targets. Unlike most clipboard formats, this 
format is not provided by a source to a target, instead, a target will call 
IDataObject::SetData to communicate information about a paste operation back to 
the source. The format can be seen as the logical equivalent to the return value 
from DoDragDrop; if it is DROPEFFECT MOVE, then the source must complete the 
move operation by removing the original data. 


“InShellDragLoop” - This is an HGLOBAL that contains a DWORD that is either 0 or 
non-zero, and is intended to allow data objects to optimize data rendering during 
DoDragDrop. A value of non-zero indicates that the data object is within the drag 
loop, meaning any future calls to the data object are likely being made by drop 
targets querying information as part of drag loop processing. A zero value indicates 
that the data object is no longer in the drag loop, meaning that any future calls to 
the data object are likely being made by the drop target that is to receive the data. 
A data object implementation can use this knowledge to avoid performing expensive 
rendering of data while the user is dragging the object, and to allow expensive 
rendering when the object is actually dropped. This is useful because several 
application drop targets incorrectly call IDataObject::GetData within the drag loop, 
which can be a costly operation and cause the drag cursor to stall. The data object 
should still include expensive to render data formats in the FORMATETC 
enumerator and in calls to IDataObject::QueryGetData. If the format is not set in 
the data object, it should behave as if the value is zero. 


Shell Extensions for Drag and Drop 


For applications that want to make the file types they manage participate in drag 
and drop beyond the standard CF HDROP handling there are two types of shell 
extensions to be aware of. 


Drop Target Shell Extensions lets you install a handler the implements IDropTarget 
for files of a given type. This is how drag and drop onto a shortcut works. When you 
drop on a shortcut it redirects the drop through it’s own IDropTarget 
implementation to the target of the shortcut. 


Data Object Shell Extensions let you add to the data object that is created when a 
file is picked up to be dragged or copied to the clipboard. This is how scraps work, 
when you pick up a scrap you are not only dragging a CF HDROP, you are also 
dragging EMBEDSOURCE (and other data under control of the scrap source). This 
could be used to make text files be represented as CF TEXT when they are dragged. 


See the documentation on shell extensions for more information on how these work. 


Special Drop targets in the shell. 
EXEs 
Printers 
My Computer 
Net hood 


Default effect given different types volumes 


Scraps and Document Shortcuts 


Scraps and document shortcuts allow users to select part of a document in an OLE 
enabled application, and drag that (or cut/copy/paste) into a folder and have a file 
created that contains that data (Scrap) or is a link to that data (Document Shortcut). 
This is implemented using the standard OLE clipboard formats, 

CF EMBEDSOURCE, and CF LINKSOURCE, a scrap is just a persisted OLE 
embedding or link. The scrap can be transfer back into any OLE enabled 
application. 


Round Trips, Exploding Embeddings 


In the case where an application is receiving it’s own data back from a scrap or any 
other sequence of transfers from other OLE apps, known as a round trip, it is 
recommended that the embedding be merged back into the native format instead of 
being kept as an embedding. This is known as exploding the embedding. This 
following scenario describes what happens. A user selects a piece of a document, 
then drags that out to the desktop. The shell recognizes that the data object can be 
used to create a scrap (it contains CF EMBEDSOURCE), the scrap is created 
containing that data. The user then picks that scrap up and drags it back to the app. 
The shell represents that data as an embedding (that is what a scrap is), and the app 
accepts the drop. In this case if the data was not exploded then it would come back 
to the app as an embedding (of the apps native data) in the apps document. This is 
typically not a useful thing, and not what the user expects. The same scenario can 
happen when going through a series of transfers between OLE apps. In both cases it 
is best to explode the data. 


Fixing specific inter-application scenarios 


There are a few common cases where you want more in a scrap that just an 
embedding or link. For applications that are not OLE containers but do accept other 
data formats can’t accept a scrap (they don’t accept OLE embeddings). Some 
application suites may want to communicate private formats to each other through 
scraps. Some round trip problems can be solved by offering the right formats in the 
scrap if apps prefer some private formats over embeddings. The solution to these 
problems is to allow the source of a transfer to add extra formats to the scrap. This 
is controlled by information stored in the registry under the CLSID of data source 
(embedding). For example, this allows a scrap to contain “Rich Text Format” along 
with the embedding, or to enumerate CF TEXT along with the embedding. Under 


the CLSID for the source embedding object (the CLSID that's in the 
OBJECTDESCRIPTOR that you put up with it), you can add the following keys: 


HKEY_ CLASSES ROOT\CLSID\{...}\DataFormats 
PriorityCacheFormats 


<n=0, 1, 2, ...> = <format n> 
DelayRenderFormats 


<n=0, 1, 2, ...> = <format n> 


Where <format n> is the string of the registered format, for example “Rich Text 
Format” or the “#X” where X is the clipboard format number of the standard 
windows clipboard constants. 


PriorityCacheFormats are formats which scraps copies in their entirety from the 
data-object into the scrap on drop and offers up when it sources a later drag. Use 
this sparingly, as it is time and space consuming on disk, obviously. 
DelayRenderFormats are formats which scraps do not actually copy 
intoremembersbynamein the scrap on drop butand offers up in the data-object 
when it sources a later drag. if the target requests the data (GetData/GetDataHere), 
scraps "delay renders" the format by loading and running the OLE object and then 
delegating the data request to the running object._Note that this registry entries are 


read when the data-object is created by the shell, not at the creation of the scrap 
file. 


Name generation of Scraps 


The name for a scrap comes from the “short name” registered for the CLSID of the 
object, and the CF_TEXT of data object. 


Packager 


A packager is an OLE object (to be embedded into an arbitrary OLE container) 


which contains either a file, a command line, or an embedded object. However, the 
only useful feature on Win95 is the file packager. There is no reason to have a 
packagez object that contains an embedded object any more, because OLE 2.0 
directly supports the iconic view of an embedded object. A file packager that 
contains a shell shortcut file works much better than a command-line packager. 

A file package is typically created when a file is dragged from the shell and 
dropped onto the client area of a document. The drop target application should try 
to get a format of data which it can handle directly (such as CF TEXT or 

CF EMBEDDEDOBJECT) first. Only if the data object offers none of them, it should 


ask for CF HDROP and call OleCreateFromFile for each file in that hdrop. This is 
one of keys to make the round trip working correctly - remember that a scrap file 


offers both CF EMBEDDEDOBJECT and CF_HDROP. 


Cursors and drag images 


There are a two different approaches for managing the visual feedback during a 
drag operation. The conventional method that OLE specification describes works as 
follows; the target indicates what default type of transfers is (move, copy, link or 
nothing), the source uses information to set the cursor, typically using the default 
cursors built into the system. It is the targets responsibility to highlight the drop 
target and render the item being dragged when appropriate. There is another 
approach, where the target takes over drawing of the item being dragged and the 


cursor. This requires the target to turn off the regular cursor, merge together the 
image of the item, the cursor, and the default transfer type into an image, this is 
shown below. This allows 


Start MeWlp mn 


Move Copy Link Cursor 
Cursor Cursor 


Application guidelines 


As a Source 


Support left and right drag. This is trivial_(as far as it pops up the context menu on 
the right mouse button up as the UI quide suggests), the sample code below can be 


used. 

Use standard feedback cursors. 

Offer “File like” objects as FILECONTENTS and GROUPFILEDESCRIPTOR, so that 
the target can create a file (or files) from the data object without knowing the 
format of the file. 

Use the data object from the embedded object itself OLE embeddings if a single 
embedded object is dragged, so you get the extra formats it may offers (packager)_ 
and avoid creating an extra layer of containment. When dragging an embedded 
object of server A from server/container B and dropping into container C should not 
create an embedded object of server B (that contains an embedded object of server 
A), it should simply create an embedded object of server B. 

If you deal with existing files, offer them through CF_HDROP. 


As a Target 


Implement and register your OLE drop target and don’t bother with Win3.1 target 
or WM _DROPFILES. 

Accept CF HDROP, FILECONTENTS 

Support right drag. 


Optimized Move 


Typical Drag and Drop scenarios have the target make a copy of the data at the 
target, then the source is instructed to delete the source data when DoDragDrop() 
returns DROPEFFECT MOVE. This is inefficient in many cases, as it requires two 
copies of the data and in some cases it is impractical, specifically when operating on 
large persistent data like the a system or a database. Optimized move is the term 
used to describe the case where the target breaks the typical protocol and moves 
the data itself, using knowledge of the underlying storage of the data. In the 
cut/copy/paste case the target knows that the source did a cut by the presence of a 
0 in the “Preferred DropEffect” format and DROPEFFECT MOVE in the “Paste 


Succeeded” format. For this to work properly for “delete on paste” apps the target 
must conform to the standard described in the “delete on paste” section. 


Clipboard specific Issues 


“Delete On Paste” Cut model 


In some applications the traditional implementation of “Cut” where the data 
disappears when the command is invoked is not appropriate. This can be both for 
either for efficiency and usability reasons, users can be afraid of the state where the 
cut object is no longer visible, pending transfer. Instead of deleting the data at cut 
time, they mark the data visually, and delete it after the paste operation succeeds. 
This is known as the “delete on paste” cut model. This is what Excel and the 
Windows 95 shell do. This model has problems with the standard clipboard 
transfers, as the source of the transfer does not know when the paste is complete. A 
convention has been adopted to solve this problem, where the application 
implementing the paste can signal back to the source through 
IDataObjetct::SetData. The transaction operates as follows: When the user chooses 
cut or copy in the source container, the source provides a 

“Preferred DropEffect” indicating which type of transfer is preferred. (“Cut” implies 
DROPEFFECT MOVE while “Copy” implies DROPEFFECT COPY | 

DROPEFFECT LINK.) When the object is pasted, the target container decides what 
type of transfer is being performed, taking the Preferred DropEffect into account. If 
the target is performing a move but cannot perform an “optimized move” (i.e. 
cannot delete the original data itself), then it must signal the source to complete the 
move by calling IDataObject::SetData with the “Performed Effect” format with a 
value of 0 and then the “Paste Succeeded” format with a value of 
DROPEFFECT MOVE . 


Tips and Tricks and Issues 


Target highlighting 

Right drag implies context menu on mouse up 

Window activation on drop (inter thread case is special) 

Window activation on begin drag (mouse down) in overlapped window scenarios. 


Open file when dropped on non client area, embed when dropped within a 
document. 


Multiple file open case 

Implement “PrintTo” for the printer object. 
Use OleQueryCreateFromData() 
Auto-Scrolling / Auto Open 


Use drag rectangle before starting drag. 


The taskbar is a special drop target that allows users to switch between apps by 
hovering over buttons that represent each app. It does not actually accept a drop, it 
just watches for DragOver events. The Start button is also a target, which will 
create a link in the “Start Menu” folder to whatever is dragged onto it. For [F4 
hovering over blank areas in the tray will minimize all windows. This facilitates 
dragging from full screen applications to the desktop. Applications do not need to be 
aware of this functionality but it should be understood when specific user scenarios 
are being designed. 


Command line handling use quotes to separate LFNs with spaces, convert short 
names to long. 


Extra clipboard formats and “FileName” compatibility with MS Mail 3.2 and Word 6 
(in copy/paste case). 


Accept your native format, even if you are not really a target to avoid no drop cursor 
when dragging out of yourself. 


File dialogs are drop sources & targets. 
Sample code: 


Implementation of IDropSource that implements both left and right drag. 
Auto-Scroll code 

Delegating the drop target to a treeview or listview. 

Context menu for right drag target support. 

IDList manipulation code (idlist.c). 

Implementing “Create Shortcut” for IDList data and LINKSOURCE. 


Link deref on drop. 
Notes for shell changes: 


fix Open With... to sniff out use quotes or not 
IDataObject through command line 
exe registration for drag drop command line format 


Make OleQueryCreateFromData() support FILECONTENTS. 


Known issues with Win95 


If you don’t have CF_HDROP but do have both FILECONTENTS and CF_HIDA in the 
same data object, only “Create Shortcut” (link) is offered to the end user, not Move or 
Copy. This is fixed in IE4. 


Positioning multiple items using the OFFSETS format for items offered through 
FILECONTENTS/GROUPFILEDESCRIPTOR does not work. (verify with davidpl). 


When transferring objects through FILECONTENTS/GROUPFILEDESCRIPTOR there is 
no progress UI. 


When doing a drag and drop with DROPEFFECT_LINK and CF_FILECONENTS on drop a 
message box appears that asks to confirm creating the shortcut. “You can not move 
or copy this item to this location. Would you like to create a shortcut to the item 
instead” <Yes> <No>. /n /JE4 a source can override this behavior by also providing a 
“Preferred DropEffect” which is exactly equal to DROPEFFECT_ LINK. Application 
developers should consider the usability impact of overriding this message. (If a user 
would be confused that the object was not moved or copied, it is usually better to 
inform them of why...) 


You need to provide CF_HIDA (even if you already provide CF_HDROP) to get “Create 
Shortcut” functionality. 


For CF_HDROP the shell always implements “optimized move” (moving the files 
itself), but erroneously returns DROPEFFECT MOVE anyway. This can confuse 
sources that properly delete data when DROPEFFECT_ MOVE is returned. The best 
workaround is to avoid any error UI if the delete operation fails because the data is 
already gone. This cannot be fixed because some applications have now depended 
upon this behaviour (Lotus SmartSuite for example). 


If a source does not use optimized move but instead returns DROPEFFECT MOVE, the 
shell will fail to delete the source files. This is fixed in IE4 if we detect the “Performed 
Effect” format. This format is required because some applications process drop ona 
separate thread, so if we silently try to delete the files upon return from 
/DataObject::Drop we will steal them out from under the thread that is processing the 
Drop. For compatibility with targets that improperly return DROPEFFECT_MOVE, the 
shell will not put up UI! if it encounters an error deleting the source material.) 


New IE4 Drag and Drop features 


Hovering over a folder in the tree pane of the Explorer during a drag will auto-expand 
that folder in the tree if it is not already open. This allows the user to navigate the 
namespace during drag-drop. 


Hovering over an empty part of the taskbar during a drag will perform a “Minimize 
All” so that the user can drop on the desktop. 


